NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/9345

Internet Message Format | 1996-08-05 | 6.4 KB

Path: news.niestu.com!usenet
From: [e-mail] (Chip Richards)
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Subject: Re: C/C++ knocks the crap out of Ada
Date: 1 Mar 1996 00:48:19 GMT
Organization: NiEstu, Phoenix AZ USA
Message-ID: <4h5hgj$[e-mail]>
References: <[e-mail]> <4etcmm$[e-mail]>
  <4f4ptt$[e-mail]> <4g1b7n$[e-mail]>
  <[e-mail]> <4gaa6l$[e-mail]>
  <4gd94r$[e-mail]> <[e-mail]>
  <[e-mail]>
NNTP-Posting-Host: tomquartz.niestu.com
X-Newsreader: knews 0.9.3

Sigh.

In article <[e-mail]>, Kazimir Kylheku writes:

   What is intrinsically unsafe about C?

Lots of things.  How much time have you?

My current employer produces industrial process control systems.  Ada and C
were considered for the implementation back in 1981, but neither was
sufficiently well-supported on the "mandated" hardware, so an extended Pascal
was chosen instead.  That decision has paid off repeatedly in terms of
reliability, which translates directly into a reduction in certain unpleasant
side-effects such as down-time, explosions, lawsuits, and even injuries and
death.

The most common failure for one of these control computers is "range check",
which is completely missing from C.  Certainly, a C coder *could* add range
checks, but so could those Pascal programmers.  However, if they had, the
compiler-generated checks would not be triggered.  C programmers, feeling
"close to the hardware" and so often paying homage to the god of "efficiency",
fail to put checks in just as often, but their compiler provides no option for
backing them up in those instances.

There actually was an over-zealous vice-president who, upon learning that the
most common error was a range check, suggested that all the range checks be
removed from the code, thus preventing the majority of errors!  Cooler heads,
who understand that it is much better (given the control system architecture)
to simply stop processing than to continue processing with erroneous data,
prevailed, and the range checks are still shipping.

   I could write a strict, standard-conforming, anally-retentive program in
   any language that could kill people (maliciously, of course).

So you could.  So could I, so could anyone.  What is much more the treat (and
much more difficult) is to write a program (*any* program) which does *not*
kill people, even when it is entrusted with their safety.  The skill lies not
in writing a dangerous program intentionally, but in *not* writing such a
program *unintentionally*.

   Software which has life-threatening consequences shoud not be left to
   something that sacrifices intimacy with hardware for some higher purpose
   that has more to do with bureaucracy than anything else.

This statement is astounding.  Starting at the end:

1.  "... some higher purpose that has more to do with bureaucracy than
anything else."  I assume this is a jab at Ada.  It's wrong.  If you would
care to correct this mistaken impression, spend a bit of time and learn a
little of the history of the language you attempt to disparage.  Pay special
attention to the birth of Ada95, which has precious little to do with
bureaucracy.  Granted, some design decisions were put into Ada83 (and even a
scant few in Ada95) more to create a pleasing political compromise than a
pleasing technical design.  But there were still sound technical arguments
behind *every* feature.

2.  "... something that sacrifices intimacy with hardware ..."  Ex*cuse* me?
What??  What *are* they teaching in today's schools?  The only hardware C has
anything *like* intimacy with is the PDP-11, its spawning ground.  As a system
programming language for the 11's, it was years ahead of its time--other
system languages of the time (many popular platforms had one) were cumbersome,
primitive, and specialized in the extreme.  But the "intimacy with hardware"
remark could only be applied by someone who hasn't spent much time actually
writing C which is intimate with hardware.  Especially with several different
platforms.  Sigh--more research on your calendar to dispel this particular
myth.

3.  "Software which has life-threatening consequences shoud not be left to
.."  Wow, should not be left to people who hold such astounding
misconceptions, I'd say.

In literal point of fact, I agree with this statement.  If it applied to
something in the real world, it would be a rather more interesting statement.

   And it should certainly not be written in some poorly standardized language,
   for which no two implementations are in agreement.

Agreed, but it's odd that you would set this criterion, since it rules out C
*and* C++, and allows Ada83 and even *begs* for Ada95.  Or did someone rush
out and write a validation suite for C or C++ while we weren't looking?  While
the ACVC is no guarantee of much of anything, it *is* better than, er,
nothing.

   C is governed by an ISO standard, which, if adhered to, lets a strictly
   conforming program translated by a strictly conforming implementation yield
   well-defined results.

Oh, this is rich!  Have the words "implementation defined" been driven from
that spec?  Have they at least been eliminated from the *important* areas,
like bitfields?  Formality of specification and predictability of results are
attributes that all languages possess to smaller or greater degree; I would
venture to say that C++ exceeds C in these areas, and Ada exceeds C++.  And
Ada could itself stand some work.

   I don't think you can say the same for Ada or C++.

Well, obviously *you* can't say that about Ada or C++, but only because you
are underinformed.  I can say it fine:  Ada95 is *already* an ISO standard,
and C++ is well along its way to becoming one.

BTW, my employer's architects decided that their new control systems should be
written in C/C++.  And for those people who don't think there *is* such a
language as C/C++, I beg to differ.  "C/C++" is that language that is written
mainly using the syntactic rules of C, and compiled with a C++ compiler.  That
way, you can tell your boss and your customer that the system is written in
C++, without the actual pain and fright of OO design and implementation.  And
you can always drop into C when the C++ "isn't suitable" for whatever task you
don't have the schedule to *write*, but must hack up like a furball.

--
Chip